The description of the invention herein is intended to provide information for one skilled in the art to understand and practice the full scope of the invention, but is not intended to be limiting as to the scope of available knowledge, nor admit that any particular reference, nor the combinations and analysis of this information as presented herein, is itself a part of the prior art. It is, in fact, a part of the present invention to aggregate the below cited information as a part of the disclosure, without limiting the scope thereof. All of the below-identified references are therefore expressly incorporated herein by reference, as if the entirety thereof was recited completely herein. It is particularly noted that the present invention is not limited by a narrow or precise discussion herein, nor is it intended that any disclaimer, limitation, or mandatory language as applied to any embodiment or embodiments be considered to limit the scope of the invention as a whole. The scope of the invention is therefore to be construed as the entire literal scope of the claims, as well as any equivalents thereof as provided by law. It is also understood that the title, abstract, field of the invention, and dependent claims are not intended to, and do not, limit the scope of the independent claims.
Real-time communications are typically handled by dedicated systems which assure that the management and control operations are handled in a manner to keep up with the communications process, and to avoid imposing inordinate delays. In order to provide cost-effective performance, complex processes incidental to the management or control of the communication are typically externalized. Thus, the communications process is generally unburdened from tasks requiring a high degree of intelligence, for example the evaluation of complex algorithms and real time optimizations. One possible exception is least cost routing (LCR), which seeks to employ a communications channel which is anticipated to have a lowest cost per unit. In fact, LCR schemes, when implemented in conjunction with a communications switch, either employ simple predetermined rules, or externalize the analysis.
Modern computer telephone integrated systems typically employ a general purpose computer with dedicated voice-communication hardware peripherals, for example boards made by Dialogic, Inc. (Intel Corp.). The voice communication peripherals execute the low level processing and switching of the voice channels, under control from the general purpose processor. Therefore, the voice-information is generally not communicated on the computer bus. This architecture typically allows the computing platform to run a modern, non-deterministic operating system, such as Windows 2000, without impairing the real-time performance of the system as a whole, since the communications control functions are not as time critical as the voice processing functions. However, as is well known, non-deterministic operating systems, such as Windows 2000, are subject to significant latencies, especially when multiple tasks are executing, and when contention exists between resources, especially hard disk access and virtual memory. Therefore, in order to assure that system operation is unimpeded by inconsistent demands on the platform, typically the host computer system for the telephony peripherals is ‘dedicated’, and attempts are made to eliminate extraneous software tasks. On the other hand, externalizing essential functions imposes potential latencies due to communications and external processing.
The Call Center
A ‘call center’ is an organization of people, telecommunications equipment and management software, with a mission of efficiently handling electronic customer contact. A typical call center must balance competing goals. Customers should experience high quality and consistent service as measured, for example, by how long the customer's call must wait in queue before being answered and receiving satisfactory service. At the same time, this service should be provided to make efficient use of call center resources.
Strategies for Call Center Management ‘Workforce management’ systems provide important tools for meeting the goals of the call center. These systems generate forecasts of call volumes and call handling times based on historical data, to predict how much staff will be needed at different times of the day and week. The systems then create schedules that match the staffing to anticipated needs. Typically, an Automatic Call Distribution (ACD) function is provided in conjunction with a computerized Private Branch Exchange (PBX). This ACD function enables a group of agents, termed ACD agents, to handle a high volume of inbound calls and simultaneously allows a queued caller to listen to recordings when waiting for an available ACD agent. The ACD function typically informs inbound callers of their status while they wait and the ACD function routes callers to an appropriate ACD agent on a first-come-first-served basis. Today, all full-featured PBXs provide the ACD function and there are even vendors who provide switches specifically designed to support the ACD function. The ACD function has been expanded to provide statistical reporting tools, in addition to the call queuing and call routing functions mentioned above, which statistical reporting tools are used to manage the call center. For example, ACD historical reports enable a manager to identify times: (a) when inbound callers abandon calls after long waits in a queue because, for example, the call center is staffed by too few ACD agents and (b) when many ACD agents are idle. In addition, ACD forecasting reports, based on the historical reports, allow the manager to determine appropriate staffing levels for specific weeks and months in the future.
Queue Management
ACD systems experience high traffic periods and low traffic periods. Consequently, ACD systems must be capable of automating two major decisions. The first major decision may be referred to as the ‘agent selection decision,’ i.e., when more than one agent is available to handle the next transaction, which agent should be chosen? The second major decision may be referred to as the ‘transaction selection decision,’ i.e., when more than one transaction is waiting for the next available agent and an agent becomes available, which transaction should the agent handle? One approach to the agent selection decision is to set up a sequencing scheme, so that the switch of the ACD system follows the same sequence of agents until the first available agent in the sequence is found. The concern with this approach is that it creates ‘hot seats,’ i.e. an inequitable distribution of inbound calls to ACD agents who are high in the sequence. Most current ACD systems solve the agent selection decision by using a longest-idle-eligible-agent approach to provide a more equitable distribution of transactions.
There are also different approaches to the transaction selection decision in which there are more available transactions than there are ACD agents. One approach is to create one or more first-in, first-out (FIFO) queues. Under this approach, each transaction may be marked with a priority level by the switch of the ACD system. When an agent becomes available, the transaction with the highest priority is routed to the agent. If several calls of equal priority are waiting in a queue, the call which has been waiting the longest is routed to the available agent. If the call center conducts outbound transactions, each transaction is similarly submitted to a FIFO queue with a priority designation, with the switch routing transactions from the queue to the agents.
Queue/Team Management
Calls that arrive at a call center generally are classified into ‘call types’ based on the dialed number and possibly other information such as calling number or caller responses to prompts from the network. The call center is typically served by an automatic call distributor (ACD), which identifies the call type of each incoming call and either delivers or queues it. Each call type may have a separate first-in-first-out queue in the ACD. In most existing call centers, the agents answering calls are organized into one or more ‘teams,’ with each team having primary responsibility of the calls in one or more queues. This paradigm is sometimes referred to as ‘queue/team.’ In the queue/team model, scheduling for each team can be done independently. Suppose, for example, that the call center handles calls for sales, service, and billing, and that each of these call types is served by a separate team. The schedule for sales agents will depend on the forecast for sales call volume and on various constraints and preferences applicable to the agents being scheduled, but this schedule is not affected by the call volume forecast for service or billing. Further, within the sales team, agents are typically considered interchangeable from a call handling viewpoint. Thus, within a team, schedule start times, break times and the like, may be traded freely among agents in the team to satisfy agent preferences without affecting scheduled call coverage. See, U.S. Pat. No. 5,325,292, expressly incorporated herein by reference. In a queue/team environment, when a new call arrived, the ACD determines the call type and places it in the queue, if all agents are busy, or allocates this call to the team member who had been available the longest.
Skill-Based Routing
Skill-based routing of agents is a well known principle, in which the agent with the best match of skills to the problem presented is selected for handling the matter. Typically, these matters involve handling of telephone calls in a call center, and the technology may be applied to both inbound and outbound calling, or a combination of each. The skill-based routing algorithms may also be used to anticipate call center needs, and therefore be used to optimally schedule agents for greatest efficiency, lowest cost, or other optimized variable.
In the case of multi-skill criteria, the optimality of selection may be based on a global minimization of the cost function or the like.
The longest-idle-agent approach and the FIFO approach function well in applications having little variation in the types of transactions being handled by the ACD agents. If all agents can handle any transaction, these approaches provide a sufficiently high level of transactional throughput, i.e., the number of transactions handled by the call center in a particular time interval. However, in many call center environments, the agents are not equally adept at performing all types of transactions. For example, some transactions of a particular call center may require knowledge of a language other than the native language of the country in which the call center is located. As another example, some transactions may require the expertise of ‘specialists’ having training in the specific field to which the transaction relates, since training all agents to be knowledgeable in all areas would be cost-prohibitive. For ACD applications in which agents are not equally adept at performing all transactions, there are a number of problems which at least potentially reduce transactional throughput of the call center. Three such problems may be referred to as the ‘under-skilled agent’ problem, the ‘over-skilled agent’ problem, and the ‘static grouping’ problem.
The under-skilled agent problem reduces transactional throughput when the switch routes transactions to ACD agents who do not have sufficient skills to handle the transactions. For example, a call may be routed to an English-only speaking person, even though the caller only speaks Spanish. In another example, the transaction may relate to product support of a particular item for which the agent is not trained. When this occurs, the agent will typically apologize to the customer and transfer the call to another agent who is capable of helping the customer. Consequently, neither the agent's nor the customer's time is efficiently utilized.
Inefficient utilization is also a concern related to the over-skilled agent problem. A call center may have fixed groupings of agents, with each group having highly trained individuals and less-experienced individuals. Call-management may also designate certain agents as ‘specialists,’ since it would be cost prohibitive to train all agents to be experts in all transactions. Ideally, the highly skilled agents handle only those transactions that require a greater-than-average skill level. However, if a significant time passes without transactions that require highly skilled agents, the agents may be assigned to calls for which they are over-qualified. This places the system in a position in which there is no qualified agent for an incoming call requiring a particular expertise because the agents having the expertise are handling calls that do not require such expertise. Again, the transactional throughput of the call center is reduced.
Current ACD systems allow agents to be grouped according to training. For example, a product support call center may be divided into four fixed, i.e., ‘static,’ groups, with each group being trained in a different category of products sold by the company. There are a number of potentially negative effects of static grouping. Firstly, the call center management must devise some configuration of agents into groups. This may be a costly process requiring extensive analysis and data entry. Secondly, the configuration that is devised is not likely to be optimal in all situations. The pace and mix of transactions will change during a typical day. At different times, the adverse effects of the under-skilled agent problem and the adverse effects of the over-skilled agent problem will vary with respect to the transactional throughput of the call center. Thirdly, when a new product is released, the devised configuration likely will be less valuable. In response to changes in the size, pace and mix of the transaction load over the course of time, call management must monitor and adjust the performance of the current grouping configuration on an ongoing basis. When trends are detected, the grouping configuration should be changed. This requires the time and attention of call center managers and supervisors. Again, the transactional throughput is reduced.
It is thus known in the prior art to provide ACD systems that depart from the queue/team model described above. Calls are still categorized into call types. In place of queues for the call types, however, queues associated with ‘skills’ are provided. The ACD's call distribution logic for the call type determines which queue or queues a call will occupy at various times before it is answered. Agents are not organized into teams with exclusive responsibility for specific queues. Instead, each agent has one or more identified ‘skills’ corresponding to the skills-based queues. Thus, both a given call and a given agent may be connected to multiple queues at the same time. Agent skills designations may be further qualified, for example, as ‘primary’ or ‘secondary’ skills, or with some other designation of skill priority or degree of skill attainment. The ACD call distribution logic may take the skill priority levels into account in its call distribution logic.
In a skills-based routing environment, the ‘matching’ of calls to agents by the ACD becomes more sophisticated and thus complicated. Agents who have more than one skill no longer ‘belong’ to a well-defined team that handles a restricted set of calls. Instead, the skills definitions form ‘implicit’ teams that overlap in complex ways. If, for example, a call center has 10 skills defined, then agents could in principle have any of 1024 possible combinations (210) of those skills. Each skill combination could be eligible to handle a different subset of the incoming calls, and the eligible subset might vary with time of day, number of calls in queue, or other factors used by the ACD in its call routing decisions. Today, call center managers want to connect a caller to an ACD agent having exactly the right skills to serve the caller. However, ‘skills based’ ACD agent groups are often small and, as a result, whenever an inbound call arrives, all such ‘skills based’ ACD agents may be busy. In such instances, the ACD function can take call back instructions from the caller and the ACD function can manage the call back functions, for example, by assigning such calls, in accordance with the caller instructions, to a ‘skills based’ ACD agent whenever one becomes available.
Scheduling of agents in a skills-based environment is thus a much more difficult problem than it is in a queue/team environment. In a skills-based environment, call types cannot be considered in isolation. Thus, for example, a heavy volume of Service calls might place higher demands on multi-skilled agents, causing an unforeseen shortage of coverage for Billing calls. Further, agents with different skills cannot be considered interchangeable for call handling. Thus, trading lunch times between a Sales-only agent and a multi-skill agent might lead to over-staffing Sales at noon while under-staffing Service at 1:00 p.m. This would lead to undesirable results. Moreover, with respect to the needs of a particular call type, a multi-skilled agent might provide no help over a given span of time, might be 100% available for calls of that type, or might be available part of the time and handling other call types for another part of time.
All agents having a particular combination of skills may be deemed a ‘skill group.’ A central problem of skills-based scheduling is then finding a way to predict what fraction of scheduled agents from each skill group will be available to each call type during each time interval being scheduled. If these fractions are known, then the effect of different agent schedules can be generated. Unfortunately, it is difficult or impossible to calculate the skill group availability fractions directly. These functions depend on the relative and absolute call volumes in each call type, on the particulars of the skills-based call distribution algorithms in the ACD, and on the skills profiles of the total scheduled agent population. Particularly as ACD skills-based routing algorithms themselves evolve and become more sophisticated, the factors affecting skill group availability become too complex for direct analysis. One proposed solution provides a feedback mechanism involving call handling simulation and incremental scheduling, to schedule agents in a skills-based routing environment. See, U.S. Pat. No. 6,044,355, expressly incorporated herein in its entirety.
In accordance with this ‘skills-based scheduling’ method, a computer implemented tool is used to determine an optimum schedule for a plurality of scheduled agents in a telephone call center, each of the plurality of scheduled agents having a combination of defined skills. The plurality of scheduled agents are organized into ‘skill groups’ with each group including all scheduled agents having a particular combination of skills. The method begins by generating a plurality of net staffing arrays, each net staff array associated with a given call type and defining, for each time interval to be scheduled, an estimate of a difference between a given staffing level and a staffing level needed to meet a current call handling requirement. In addition to the net staffing arrays, the method uses a plurality of skills group availability arrays, each skills group availability array associated with the given call type and defining, for each combination of skill group and time interval to be scheduled, an estimate of a percentage of scheduled agents from each skill group that are available to handle a call. According to the method, the plurality of arrays are used to generate a proposed schedule for each of the plurality of scheduled agents. Thereafter, a call handling simulation is then run against the proposed schedule using a plurality of ACD call distribution algorithms (one for each call type being scheduled). Based on the results of the call handling simulation, the net staffing arrays and the skills availability arrays are refined to more accurately define the net staffing and skills usage requirements. The process of generating a schedule and then testing that schedule through the simulator is then repeated until a given event occurs. The given event may be a determination that the schedule meets some given acceptance criteria, a passage of a predetermined period of time, a predetermined number of iterations of the process, or some combination thereof. A proposed schedule is ‘optimized’ when it provides an acceptable call handling performance level and an acceptable staffing level in the simulation. Once the proposed schedule is ‘optimized,’ it may be further adjusted (within a particular skill group) to accommodate agent preferences.
U.S. Pat. No. 5,206,903 to Kohler et al. describes ACD equipment which uses static grouping. Each static group of agents is referred to as a ‘split,’ and each split is associated with a different queue. The agents are assigned to splits according to skills. Within a single split, the agents may be limited to knowledge of different subtypes of transactions. Preferably, there is at least one agent in each split who is trained to handle calls of any of the subtypes within the particular split. This ‘expert’ may also be trained to efficiently handle calls of other types, i.e., other splits. Each agent possesses up to four skill numbers that represent various abilities of the agent with respect to handling transactions related to subtypes and types of transactions. The ACD equipment assigns each incoming call three prioritized skill numbers that estimate skill requirements of the incoming call. The skill numbers of the incoming call are considered ‘prioritized,’ since they are viewed sequentially in searching for a match of the call with an agent, so that the second skill number of the call is unnecessary if a match is found using the first prioritized skill number. The incoming call is assigned the one, two or three prioritized skill numbers and is placed in the appropriate queue of the appropriate static group of agents. A search is made among the available agents for an agent-skill number that matches the first skill number of the call. If no match is found after a predetermined time delay, the second prioritized skill number of the call is used to find a match. If no match is found after a second predetermined time delay, the third prioritized skill number is considered. Then, if no match is still found, the ACD equipment of Kohler et al. expands the search of available agents to other groups of agents.
While the Kohler et al. patent does not directly address the problems associated with static groups, it does consider the skills of the individual agents. The prioritized skill numbers assigned to the incoming calls are logically ordered. The patent refers to the first skill number of a call as the primary call-skill indicator. This primary indicator is used to define the minimal skill level that is required for an agent to competently handle the call. Consequently, if a match is made with the primary indicator, the ACD agent may not be over-skilled or under-skilled. However, if the search is unsuccessful, the secondary call-skill indicator is utilized. The search for a match to the secondary indicator may cause the call to be routed to an agent having more than the minimal required skill. The third prioritized skill number that is assigned to the incoming call is referred to as the ‘tertiary’ call-skill indicator. The tertiary indicator is yet another skill level beyond what is minimally required to competently handle a call. Since the tertiary indicator is utilized only if a match is not found for either of the primary or secondary indicators, an overly skilled agent of the appropriate group will handle the call only if that agent is the only available capable agent. Thus, more highly skilled agents are assigned only when their skills are required, or no lesser-skilled agent is available to handle the call.
See, U.S. Pat. Nos. 6,529,870; 6,522,726; 6,519,459; 6,519,259; 6,510,221; 6,496,568; 6,493,696; 6,493,432; 6,487,533; 6,477,494; 6,477,245; 6,470,077; 6,466,909; 6,466,654; 6,463,299; 6,459,784; 6,453,038; and U.S. Published Patent Application No. 2003/0002646.
Group Routing
Various types of conventional automatic distributors (ACDs) are available to distribute incoming calls to a group. Reservation and information services may be provided by large companies, such as major airlines, and may consist of geographically separated groups of agents that answer incoming calls distributed to the agents by separate ACDs. Agent communication terminals (ACTs) which are connected to an ACD are utilized by the agents to process incoming calls routed to a particular ACT by the ACD.
A public branch exchange (PBX) type ACD such as a Definity® ACD available from AT&T functions as a conventional PBX and further functions as an ACD to distribute incoming calls to local agents connected to the PBX. Another type of ACD consists of the utilization of an electronic telecommunication switch such as a 5ESS® switch available from AT&T which is capable of providing ACD service when supposed by ACTs coupled to the switch. Both types of ACD typically function as independent systems which handle incoming calls and make internal decisions concerning which agent will receive a given call. Both types of ACD systems are capable of generating statistical reports which can be monitored by a workstation coupled to the ACD system to allow a supervisor to monitor call handling statistics. Such data typically represents an average of statistics for a given system.
Telephone call centers that handle calls to toll-free ‘800’ numbers are well-known in the art. Typically, a company may have many call centers, all answering calls made to the same set of 800 numbers. Each of the company's call centers usually has an automatic call distributor (ACD) or similar equipment capable of queuing calls. ACD management information systems keep statistics on agent and call status, and can report these statistics on frequent intervals. Such capabilities are in use today for centralized reporting and display of multi-location call center status. In such systems, the company will want to distribute the calls to its call centers in a way that will optimally meet its business goals. Those goals might include low cost of call handling, answering most calls within a given amount of time, providing customized handling for certain calls, and many others. It is also known in the prior art that certain call routing criteria and techniques support a broad range of business goals. These include ‘load balancing,’ caller segmentation′ and ‘geographic routing.’ Load balancing refers to distribution of calls so that the expected answer delay for new calls is similar across all the call centers. If other considerations do not dictate otherwise, load balancing is desirable because it provides optimum efficiency in the use of agents and facilities, and it provides the most consistent grade of service to callers. In special situations it might be desirable to unbalance the load in a particular way, but control over the distribution of call load is still desired.
If the caller's identity can be inferred from the calling number, caller-entered digits, or other information, that identity may influence the choice of destination for the call. Call routing based on such information is referred to as caller segmentation. Also, it has been found desirable for particular call centers to handle calls from particular geographic areas. The motivation may be to minimize call transport costs, to support pre-defined call center ‘territories’, or to take advantage of agents specifically trained to handle calls from given locations. Such techniques are known as geographic routing.
The interexchange carriers who provide 800 service today generally support some form of ‘routing plan’ to help achieve load balancing, caller segmentation and geographic routing. Typically these routing plans allow 800 call routing based on time of day, day of week, the caller's area code, caller-entered digits, and fixed percentage allocations. Predominately, however, the routing plans supported by the carriers are static in the sense that they do not automatically react to unexpected variations in incoming call volume or distribution, nor to actual call delays being experienced at each destination. Reaction to changing conditions is done via manual modification of the plan, on a time scale of minutes or hours. Recent service offerings from some interexchange carriers offer some degree of automatic reaction to changing conditions. One such offering, called ‘alternate termination sequence’ or ‘ATS’ (from AT&T), allows customers to establish maximum numbers of calls to be queued for each destination, with a pre-defined alternative when a primary destination is overloaded. Another offering, referred to as ‘intelligent routing control’ or ‘IRC’ (from MCI), allows an ACD to refuse a call from the network, again resulting in pre-defined alternative call handling. A third kind of service, AT&T's Intelligent Call Processing, lets the interexchange network pass call-by-call data to a computer.
In a conventional ACD, phone calls are processed on a first-in, first-out basis: the longest call waiting is answered by the next available agent. Answering calls across multiple automated call distributors (ACD) is typically done on a first-in, first-out basis dependent upon time of receipt of the call by each ACD, whether the call is directly connected or forwarded. Another call distribution scheme is provided in Gechter et al., U.S. Pat. No. 5,036,535. This patent discloses a system for automatically distributing telephone calls placed over a network to one of a plurality of agent stations connected to the network via service interfaces, and providing status messages to the network. Gechter et al.'s disclosed system includes means for receiving the agent status messages and call arrival messages from the network, which means are connected via a network service interface to the network. Routing means responsive to the receiving means is provided for generating a routing signal provided to the network to connect the incoming call to an agent station through the network. In the system disclosed in Gechter et al, when an incoming call is made to the call router, it decides which agent station should receive the call, establishes a call with that agent station, and then transfers the original call onto the second call to connect the incoming caller directly to the agent station and then drops out of the connection. U.S. Pat. No. 5,193,110 issued to Jones et al discloses an integrated services platform for a telephone communications system which platform includes a plurality of application processing ports for providing different types of information services to callers. In Jones et al's disclosed system, a master control unit and a high speed digital switch are used to control processing of incoming phone calls by recognizing the type of service requested by the caller and then routing the call to the appropriate processing port. The Jones et al system is disclosed as an adjunct to current switching technology in public and private networks.
Intelligent Call Management
Call centers are also used to make outbound calls, for example for telemarketing. Agents making outbound calls, referred to as outbound agents, are typically separate from ACD agents handling inbound calls and call center software separately manages outbound call lists for outbound agents to ensure that each outbound agent wastes little time in dialing or in performing overhead operations. A call center typically has multiple agents for answering incoming calls and placing outgoing calls. A call center may also have agents participating in outgoing call campaigns, typically in conjunction with an outbound call management system. Each agent may be assigned to a particular group, such as an inbound group or an outbound group. Agents can also be assigned to a supervisor team, which represents multiple agents that report to the same supervisor.
In certain situations, it is necessary to restrict an agent's activity to answering calls or handling a particular type of call (e.g., answering only incoming calls). For example, during an outbound campaign, the system placing the outbound calls and controlling the rate at which the calls are placed, e.g., a so-called predictive dialer, relies on the availability of the agent to handle an answered call. If the system places outbound calls expecting the agent to be available, but the agent instead places their own call to another agent or a supervisor, or has an incoming call connected to them, the outbound system may not have an agent available to handle an answered outbound call. Additionally, if an agent is assigned to handle incoming calls, but instead places a call to another agent or listens to voice mail messages, the number of queued incoming calls may increase, thereby increasing the waiting time experienced by the callers. ‘ITU-T Recommendation Q.1219, Intelligent Network User's Guide for Capability Set 1’, dated April, 1994, expressly incorporated herein by reference, provides considerable information on intelligent networks. One known system proposes a call-management method and system for distributing calls to a plurality of individuals, such as automatic call distribution (ACD) agents, which routes calls to the individuals based upon a correlation of attributes of the individuals with calls that are tagged with identification of abilities that are advantageous to efficiently processing the calls. That is, for each call that is to be distributed, one or more skills that are relevant to efficient handling of the call are determined and then used to route the call to an appropriate individual. In addition, call management preferences may also be accommodated.
Personalization and Collaborative Filtering
Known systems allow personalization or prediction of user type, preferences or desires based on historical data or limited information available. These known systems have been applied to a number of different domains. In a non-collaborative personalization system, the available information about a person is analyzed, and based on this information, conclusions are drawn. In a collaborative system, the available information is used to associate the person with a group of other users having common attributes. By grouping users, the data sets are more dense, permitting more detailed inferences to be drawn. The groups are defined by mapping user attributes in a multidimensional space, and then defining clusters of users having correlated traits. Further, the use of data relating to past transactions of other users allows prediction of outcomes and sequences of actions, without having a true past example of the activity from that particular user.
The following references are expressly incorporated herein by reference: U.S. Pat. Nos. 6,418,424; 6,400,996; 6,081,750; 5,920,477; 5,903,454; 5,901,246; 5,875,108; 5,867,386; 5,774,357; 6,529,891; 6,466,970; 6,449,367; 6,446,035; 6,430,558; 6,412,012; 6,389,372; 6,356,899; 6,334,131; 6,334,127; 6,327,590; 6,321,221; 6,321,179; 6,317,722; 6,317,718; 6,266,649; 6,256,648; 6,253,193; 6,236,980; 6,236,978; 6,185,683; 6,177,932; 6,170,742; 6,146,026; 6,138,119; 6,112,186; 6,112,181; 6,078,928; 6,016,475; 5,999,908; 5,560,011; 6,484,123; 6,480,844; 6,477,246; 6,421,709; 6,405,922; 6,353,813; 6,345,264; 6,314,420; 6,308,175; 6,144,964; 6,029,161; 6,018,738; 6,016,475; 6,006,218; 5,983,214; 5,867,799; and 5,790,935. See also references cited in U.S. patent application Ser. No. 10/385,389. See, U.S. Pat. Nos. 4,048,452; 4,737,983, 4,757,529; 4,893,301; 4,953,204; 5,073,890; 5,278,898; 5,309,513; 5,369,695; 5,506,898; 5,511,117; 5,519,773; 5,524,147; 5,590,188; 5,633,922; 5,633,924; 5,715,307; 5,740,240; 5,768,360; 5,825,869; 5,848,143; 5,870,464; 5,878,130; 5,901,214; 5,905,792; 5,907,608; 5,910,982; 5,915,011; 5,917,903; 5,923,745; 5,926,539; 5,933,492; 5,940,496, 5,940,947; 5,946,387; 5,953,332; 5,953,405; 5,956,397; 5,960,073; 5,963,632; 5,970,134; 5,978,465; 5,982,868; 5,987,116; 5,987,118; 5,991,391; 5,991,392; 5,991,395; 5,995,614; 5,995,615; 5,999,965; 6,002,760; 6,005,931; 6,044,146; 6,058,435; 6,061,347; 6,064,667; 6,072,864; 6,104,801; 6,115,462; 6,118,865; 6,122,358; 6,122,360; 6,122,364; 6,128,380; 6,134,530; 6,147,975; 6,157,655; 6,175,563; 6,175,564; 6,185,292; 6,223,165; 6,226,289; 6,229,888; 6,230,197; 6,233,332, 6,333,979; 6,333,980; 6,347,139; and U.S. Pat. App. Nos. 010000458 A1; 0010024497 A1; 0020006191 A1; 0020009190 A1; 0020019846 A1; and 0020021693 A1, each of which is expressly incorporated herein by reference.
Internet Auctions
On-line electronic auction systems which allow efficient sales of products and services are well known, for example, EBAY.COM, ONSALE.COM, UBID.COM, and the like. Inverse auctions that allow efficient purchases of product are also known, establishing a market price by competition between sellers. The Internet holds the promise of further improving efficiency of auctions by reducing transaction costs and freeing the ‘same time-same place’ limitations of traditional auctions. This is especially appropriate where the goods may be adequately described by text or images, and thus a physical examination of the goods is not required prior to bidding.
In existing Internet systems, the technological focus has been in providing an auction system that, over the course of hours to days, allow a large number of simultaneous auctions, between a large number of bidders to occur. These systems must be scalable and have high transaction throughput, while assuring database consistency and overall system reliability. Even so, certain users may selectively exploit known technological limitations and artifacts of the auction system, including non-real time updating of bidding information, especially in the final stages of an auction. Because of existing bandwidth and technological hurdles, Internet auctions are quite different from live auctions with respect to psychological factors. Live auctions are often monitored closely by bidders, who strategically make bids, based not only on the ‘value’ of the goods, but also on an assessment of the competition, timing, psychology, and progress of the auction. It is for this reason that so-called proxy bidding, wherein the bidder creates a preprogrammed ‘strategy’, usually limited to a maximum price, are disfavored. A maximum price proxy bidding system is somewhat inefficient, in that other bidders may test the proxy, seeking to increase the bid price, without actually intending to purchase, or contrarily, after testing the proxy, a bidder might give up, even below a price he might have been willing to pay. Thus, the proxy imposes inefficiency in the system that effectively increases the transaction cost. In order to address a flurry of activity that often occurs at the end of an auction, an auction may be held open until no further bids are cleared for a period of time, even if advertised to end at a certain time. This is common to both live and automated auctions. However, this lack of determinism may upset coordinated schedules, thus impairing efficient business use of the auction system.
In order to facilitate management of bids and bidding, some of the Internet auction sites have provided non-Hypertext Markup Language (HTML) browser based software ‘applet’ to track auctions. For example, ONSALE.COM has made available a Marimba Castanet® applet called Bidwatch to track auction progress for particular items or classes of items, and to facilitate bidding thereon. This system, however, lacks real-time performance under many circumstances, having a stated refresh period of 10 seconds, with a long latency for confirmation of a bid, due to constraints on software execution, quality of service in communications streams, and bid confirmation dialogue. Thus, it is possible to lose a bid even if an attempt was made prior to another bidder. The need to quickly enter the bid, at risk of being too late, makes the process potentially error prone. Proxy bidding, as discussed above, is a known technique for overcoming the constraints of Internet communications and client processing limitations, since it bypasses the client and telecommunications links and may execute solely on the host system or local thereto. However, proxy bidding undermines some of the efficiencies gained by a live market.
A known computer site for auctioning a product on-line comprises at least one web server computer designed for serving a host of computer browsers and providing the browsers with the capability to participate in various auctions, where each auction is of a single product, at a specified time, with a specified number of the product available for sale. The web server cooperates with a separate database computer, separated from the web server computer by a firewall. The database computer is accessible to the web computer server computer to allow selective retrieval of product information, which includes a product description, the quantity of the product to be auctioned, a start price of the product, and an image of the product. The web server computer displays, updated during an auction, the current price of the product, the quantity of the product remaining available for purchase and the measure of the time remaining in the auction. The current price is decreased in a predetermined manner during the auction. Each user is provided with an input instructing the system to purchase the product at a displayed current price, transmitting an identification and required financial authorization for the purchase of the product, which must be confirmed within a predetermined time. In the known system, a certain fall-out rate in the actual purchase confirmation may be assumed, and therefore some overselling allowed. Further, after a purchase is indicate, the user's screen is not updated, obscuring the ultimate lowest selling price from the user. However, if the user maintains a second browser, he can continue to monitor the auction to determine whether the product could have been purchased at a lower price, and if so, fail to confirm the committed purchase and purchase the same goods at a lower price while reserving the goods to avoid risk of loss. Thus, the system is flawed, and may fail to produce an efficient transaction or optimal price. An Internet declining price auction system may provide the ability to track the price demand curve, providing valuable marketing information. For example, in trying to determine the response at different prices, companies normally have to conduct market surveys. In contrast, with a declining price auction, substantial information regarding price and demand is immediately known. The relationship between participating bidders and average purchasers can then be applied to provide a conventional price demand curve for the particular product.
U.S. Pat. No. 5,890,138 to Godin, et al. (Mar. 30, 1999), expressly incorporated herein by reference in its entirety, relates to an Internet auction system. The system implements a declining price auction process, removing a user from the auction process once an indication to purchase has been received. See, Rockoff, T. E., Groves, M.; ‘Design of an Internet-based System for Remote Dutch Auctions’, Internet Research, v 5, n 4, pp. 10-16, MCB University Press, Jan. 1, 1995. U.S. Pat. No. 5,835,896, Fisher, et al., issued Nov. 10, 1998, expressly incorporated herein by reference in its entirety, provides method and system for processing and transmitting electronic auction information over the Internet, between a central transaction server system and remote bidder terminals. Those bids are recorded by the system and the bidders are updated with the current auction status information. When appropriate, the system closes the auction from further bidding and notifies the winning bidders and losers as to the auction outcome. The transaction server posts information from a database describing a lot available for purchase, receives a plurality of bids, stored in a bid database, in response to the information, and automatically categorizes the bids as successful or unsuccessful. Each bid is validated, and an electronic mail message is sent informing the bidder of the bid status. This system employs HTTP, and thus does not automatically update remote terminal screens, requiring the e-mail notification feature.
The auction rules may be flexible, for example including Dutch-type auctions, for example by implementing a price markdown feature with scheduled price adjustments, and English-type (progressive) auctions, with price increases corresponding to successively higher bids. In the Dutch type auction, the price markdown feature may be responsive to bidding activity over time, amount of bids received, and number of items bid for. Likewise, in the progressive auction, the award price may be dependent on the quantity desired, and typically implements a lowest successful bid price rule. Bids that are below a preset maximum posted selling price are maintained in reserve by the system. If a certain sales volume is not achieved in a specified period of time, the price is reduced to liquidate demand above the price point, with the new price becoming the posted price. On the other hand, if a certain sales volume is exceeded in a specified period of time, the system may automatically increase the price. These automatic price changes allow the seller to respond quickly to market conditions while keeping the price of the merchandise as high as possible, to the seller's benefit. A ‘Proxy Bidding’ feature allows a bidder to place a bid for the maximum amount they are willing to pay, keeping this value a secret, displaying only the amount necessary to win the item up to the amount of the currently high bids or proxy bids of other bidders. This feature allows bidders to participate in the electronic auction without revealing to the other bidders the extent to which they are willing to increase their bids, while maintaining control of their maximum bid without closely monitoring the bidding. The feature assures proxy bidders the lowest possible price up to a specified maximum without requiring frequent inquiries as to the state of the bidding. A ‘Floating Closing Time’ feature may also be implemented whereby the auction for a particular item is automatically closed if no new bids are received within a predetermined time interval, assuming an increasing price auction. Bidders thus have an incentive to place bids expeditiously, rather than waiting until near the anticipated close of the auction.
U.S. Pat. No. 5,905,975, Ausubel, issued May 18, 1999, expressly incorporated herein by reference in its entirety, relates to computer implemented methods and apparatus for auctions. The proposed system provides intelligent systems for the auctioneer and for the user. The auctioneer's system contains information from a user system based on bid information entered by the user. With this information, the auctioneer's system determines whether the auction can be concluded or not and appropriate messages are transmitted. At any point in the auction, bidders are provided the opportunity to submit not only their current bids, but also to enter future bids, or bidding rules which may have the opportunity to become relevant at future times or prices, into the auction system's database. Participants may revise their executory bids, by entering updated bids. Thus, at one extreme, a bidder who wishes to economize on his time may choose to enter his entire set of bidding rules into the computerized system at the start of the auction, effectively treating this as a sealed-bid auction. At the opposite extreme, a bidder who wishes to closely participate in the auction may choose to constantly monitor the auction's progress and to submit all of his bids in real time. See also, U.S. patent application Ser. No. 08/582,901 filed Jan. 4, 1996, which provides a method for auctioning multiple, identical objects and close substitutes.
E-Commerce Systems
U.S. Pat. No. 5,946,669 (Polk, Aug. 31, 1999), expressly incorporated herein by reference, relates to a method and apparatus for payment processing using debit-based electronic funds transfer and disbursement processing using addendum-based electronic data interchange. This disclosure describes a payment and disbursement system, wherein an initiator authorizes a payment and disbursement to a collector and the collector processes the payment and disbursement through an accumulator agency. The accumulator agency processes the payment as a debit-based transaction and processes the disbursement as an addendum-based transaction. The processing of a debit-based transaction generally occurs by electronic funds transfer (EFT) or by financial electronic data interchange (FEDI). The processing of an addendum-based transaction generally occurs by electronic data interchange (EDI).
U.S. Pat. No. 6,005,939 (Fortenberry, et al., Dec. 21, 1999), expressly incorporated herein by reference, relates to a method and apparatus for storing an Internet user's identity and access rights to World Wide Web resources. A method and apparatus for obtaining user information to conduct secure transactions on the Internet without having to re-enter the information multiple times is described. The method and apparatus can also provide a technique by which secured access to the data can be achieved over the Internet. A passport containing user-defined information at various security levels is stored in a secure server apparatus, or passport agent, connected to computer network. A user process instructs the passport agent to release all or portions of the passport to a recipient node and forwards a key to the recipient node to unlock the passport information.
U.S. Pat. No. 6,016,484 (Williams, et al., Jan. 18, 2000), expressly incorporated herein by reference, relates to a system, method and apparatus for network electronic payment instrument and certification of payment and credit collection utilizing a payment. An electronic monetary system provides for transactions utilizing an electronic-monetary system that emulates a wallet or a purse that is customarily used for keeping money, credit cards and other forms of payment organized. Access to the instruments in the wallet or purse is restricted by a password to avoid unauthorized payments. A certificate form must be completed in order to obtain an instrument. The certificate form obtains the information necessary for creating a certificate granting authority to utilize an instrument, a payment holder and a complete electronic wallet. Electronic approval results in the generation of an electronic transaction to complete the order. If a user selects a particular certificate, a particular payment instrument holder will be generated based on the selected certificate. In addition, the issuing agent for the certificate defines a default bitmap for the instrument associated with a particular certificate, and the default bitmap will be displayed when the certificate definition is completed. Finally, the number associated with a particular certificate will be utilized to determine if a particular party can issue a certificate.
U.S. Pat. No. 6,029,150 (Kravitz, Feb. 22, 2000), expressly incorporated herein by reference, relates to a system and method of payment in an electronic payment system wherein a plurality of customers have accounts with an agent. A customer obtains an authenticated quote from a specific merchant, the quote including a specification of goods and a payment amount for those goods. The customer sends to the agent a single communication including a request for payment of the payment amount to the specific merchant and a unique identification of the customer. The agent issues to the customer an authenticated payment advice based only on the single communication and secret shared between the customer and the agent and status information, which the agent knows about the merchant, and/or the customer. The customer forwards a portion of the payment advice to the specific merchant. The specific merchant provides the goods to the customer in response to receiving the portion of the payment advice.
U.S. Pat. No. 6,047,269 (Biffar, Apr. 4, 2000), expressly incorporated herein by reference, relates to a self-contained payment system with creating and facilitating transfer of circulating digital vouchers representing value. A digital voucher has an identifying element and a dynamic log. The identifying element includes information such as the transferable value, a serial number and a digital signature. The dynamic log records the movement of the voucher through the system and accordingly grows over time. This allows the system operator to not only reconcile the vouchers before redeeming them, but also to recreate the history of movement of a voucher should an irregularity like a duplicate voucher be detected. These vouchers are used within a self-contained system including a large number of remote devices that are linked to a central system. The central system can be linked to an external system. The external system, as well as the remote devices, is connected to the central system by any one or a combination of networks. The networks must be able to transport digital information, for example the Internet, cellular networks, telecommunication networks, cable networks or proprietary networks. Vouchers can also be transferred from one remote device to another remote device. These remote devices can communicate through a number of methods with each other. For example, for a non-face-to-face transaction the Internet is a choice, for a face-to-face or close proximity transactions tone signals or light signals are likely methods. In addition, at the time of a transaction a digital receipt can be created which will facilitate a fast replacement of vouchers stored in a lost remote device.
Micropayments
U.S. Pat. No. 5,999,919 (Jarecki, et al., Dec. 7, 1999), expressly incorporated herein by reference, relates to an efficient micropayment system. Existing software proposals for electronic payments can be divided into ‘on-line’ schemes which require participation of a trusted party (the bank) in every transaction and are secure against overspending, and ‘off-line’ schemes which do not require a third party and guarantee only that overspending is detected when vendors submit their transaction records to the bank (usually at the end of the day). A new ‘hybrid’ scheme is proposed which combines the advantages of both ‘on-line’ and ‘off-line’ electronic payment schemes. It allows for control of overspending at a cost of only a modest increase in communication compared to the off-line schemes. The protocol is based on probabilistic polling. During each transaction, with some small probability, the vendor forwards information about this transaction to the bank. This enables the bank to maintain an accurate approximation of a customer's spending. The frequency of polling messages is related to the monetary value of transactions and the amount of overspending the bank is willing to risk. For transactions of high monetary value, the cost of polling approaches that of the on-line schemes, but for micropayments, the cost of polling is a small increase over the traffic incurred by the off-line schemes.
Micropayments are often preferred where the amount of the transaction does not justify the costs of complete financial security. In the micropayment scheme, typically a direct communication between creditor and debtor is not required; rather, the transaction produces a result which eventually results in an economic transfer, but which may remain outstanding subsequent to transfer of the underlying goods or services. The theory underlying this micropayment scheme is that the monetary units are small enough such that risks of failure in transaction closure is relatively insignificant for both parties, but that a user gets few chances to default before credit is withdrawn. On the other hand, the transaction costs of a non-real time transactions of small monetary units are substantially less than those of secure, unlimited or potentially high value, real time verified transactions, allowing and facilitating such types of commerce. Thus, the rights management system may employ applets local to the client system, which communicate with other applets and/or the server and/or a vendor/rights-holder to validate a transaction, at low transactional costs.
The following U.S. Patents, expressly incorporated herein by reference, define aspects of micropayment, digital certificate, and on-line payment systems: U.S. Pat. Nos. 5,930,777; 5,857,023; 5,815,657; 5,793,868; 5,717,757; 5,666,416; 5,677,955; 5,839,119; 5,915,093; 5,937,394; 5,933,498; 5,903,880; 5,903,651; 5,884,277; 5,960,083; 5,963,924; 5,996,076; 6,016,484; 6,018,724; 6,021,202; 6,035,402; 6,049,786; 6,049,787; 6,058,381; 6,061,448; 5,987,132; 6,057,872; and 6,061,665. See also, Rivest and Shamir, TayWord and MicroMint: Two Simple Micropayment Schemes' (May 7, 1996); Micro PAYMENT transfer Protocol (MPTP) Version 0.1 (22 Nov. 95) et seq., http://www.w3.org/pub/WWW/TR/WD-mptp; Common Markup for web Micropayment Systems, http://www.w3.org/TR/WD-Micropayment-Markup (9 Jun. 99); ‘Distributing Intellectual Property: a Model of Microtransaction Based Upon Metadata and Digital Signatures’, Olivia, Maurizio, http://olivia.modlang.denison.edu/˜olivia/RFC/09/, all of which are expressly incorporated herein by reference.
See, Game Theory references cited in U.S. patent application Ser. No. 10/385,389. See, also: U.S. Pat. Nos. 4,977,595; 5,237,159; 5,392,353; 5,511,121; 5,621,201; 5,623,547; 5,679,940; 5,696,908; 5,754,939; 5,768,385; 5,799,087; 5,812,668; 5,828,840; 5,832,089; 5,850,446; 5,889,862; 5,889,863; 5,898,154; 5,901,229; 5,920,629; 5,926,548; 5,943,424; 5,949,045; 5,952,638; 5,963,648; 5,978,840; 5,983,208; 5,987,140; 6,002,767; 6,003,765; 6,021,399; 6,026,379; 6,029,150; 6,029,151; 6,047,067; 6,047,887; 6,055,508; 6,065,675; and 6,072,870, each of which is expressly incorporated herein by reference. See also, U.S. Pat. Nos. 6,243,684; 6,230,197; 6,229,888; 6,226,360; 6,226,287; 6,212,178; 6,208,970; 6,205,207; 6,201,950; 6,192,413; 6,192,121; 6,185,283; 6,178,240; 6,173,052; 6,170,011; RE37,001; 6,157,711; 6,154,535; 6,154,528; 6,151,387; 6,148,065; 6,144,737; 6,137,870; 6,137,862; 6,134,530; 6,130,937; 6,128,376; 6,125,178; 6,122,484; 6,122,364; 6,122,358; 6,115,693; 6,102,970; 6,098,069; 6,097,806; 6,084,943; 6,070,142; 6,067,348; 6,064,973; 6,064,731; 6,064,730; 6,058,435; 6,055,307; 6,052,453; 6,049,599; 6,044,368; 6,044,149; 6,044,135; 6,041,118; 6,041,116; 6,035,021; 6,031,899; 6,026,156; 6,026,149; 6,021,428; 6,021,190; 6,021,114; 6,018,579; 6,016,344; 6,014,439; 6,011,845; 6,009,149; 6,005,928; 6,005,534; 6,002,760; 5,995,948; RE36,416; 5,991,761; 5,991,604; 5,991,393; 5,987,116; 5,987,115; 5,982,857; 5,978,471; 5,978,467; 5,978,465; 5,974,135; 5,974,120; 5,970,132; 5,966,429; 5,963,635; 5,956,392; 5,949,863; 5,949,854; 5,949,852; 5,946,394; 5,946,388; 5,943,403; 5,940,813; 5,940,497; 5,940,493; 5,937,390; 5,937,055; 5,933,480; 5,930,339; 5,926,528; 5,924,016; 5,923,746; 5,918,213; 5,917,893; 5,914,951; 5,913,195; 5,912,947; 5,907,601; 5,905,979; 5,903,641; 5,901,209; 5,898,762; 5,898,759; 5,896,446; 5,894,505; 5,893,902; 5,878,126; 5,872,833; 5,867,572; 5,867,564; 5,867,559; 5,857,013; 5,854,832; 5,850,428; 5,848,143; 5,841,852; 5,838,779; 5,838,772; 5,835,572; 5,828,734; 5,828,731; 5,825,869; 5,822,410; 5,822,401; 5,822,400; 5,815,566; 5,815,554; 5,815,551; 5,812,642; 5,806,071; 5,799,077; 5,796,816; 5,796,791; 5,793,846; 5,787,159; 5,787,156; 5,774,537; 5,768,355; 5,761,285; 5,748,711; 5,742,675; 5,740,233; RE35,758; 5,729,600; 5,727,154; 5,724,418; 5,717,741; 5,703,935; 5,701,295; 5,699,418; 5,696,818; 5,696,809; 5,692,034; 5,692,033; 5,687,225; 5,684,863; 5,675,637; 5,661,283; 5,657,074; 5,655,014; 5,655,013; 5,652,788; 5,646,988; 5,646,986; 5,638,436; 5,636,268; 5,636,267; 5,633,917; 5,625,682; 5,625,676; 5,619,557; 5,610,978; 5,610,774; 5,600,710; 5,594,791; 5,594,790; 5,592,543; 5,590,171; 5,588,049; 5,586,179; 5,581,607; 5,581,604; 5,581,602; 5,579,383; 5,579,377; 5,577,112; 5,574,784; 5,572,586; 5,572,576; 5,570,419; 5,568,540; 5,561,711; 5,559,878; 5,559,867; 5,557,668; 5,555,295; 5,555,290; 5,546,456; 5,546,452; 5,544,232; 5,544,220; 5,537,470; 5,535,257; 5,533,109; 5,533,107; 5,533,103; 5,530,931; 5,528,666; 5,526,417; 5,524,140; 5,519,773; 5,517,566; 5,515,421; 5,511,112; 5,506,898; 5,502,762; 5,495,528; 5,495,523; 5,493,690; 5,485,506; 5,481,596; 5,479,501; 5,479,487; 5,467,391; 5,465,286; 5,459,781; 5,448,631; 5,448,624; 5,442,693; 5,436,967; 5,434,906; 5,432,835; 5,430,792; 5,425,093; 5,420,919; 5,420,852; 5,402,474; 5,400,393; 5,390,236; 5,381,470; 5,365,575; 5,359,645; 5,351,285; 5,341,414; 5,341,412; 5,333,190; 5,329,579; 5,327,490; 5,321,745; 5,319,703; 5,313,516; 5,311,577; 5,311,574; 5,309,505; 5,309,504; 5,297,195; 5,297,146; 5,289,530; 5,283,818; 5,276,732; 5,253,289; 5,251,252; 5,239,574; 5,224,153; 5,218,635; 5,214,688; 5,185,786; 5,168,517; 5,166,974; 5,164,981; 5,163,087; 5,163,083; 5,161,181; 5,128,984; 5,121,422; 5,103,449; 5,097,528; 5,081,711; 5,077,789; 5,073,929; 5,070,526; 5,070,525; 5,063,522; 5,048,075; 5,040,208; 5,020,097; 5,020,095; 5,016,270; 5,014,298; 5,007,078; 5,007,000; 4,998,272; 4,987,587; 4,979,171; 4,975,841; 4,958,371; 4,941,168; 4,935,956; 4,933,964; 4,930,150; 4,924,501; 4,894,857; 4,878,243; 4,866,754; 4,852,149; 4,807,279; 4,797,911; 4,768,221; 4,677,663; and 4,286,118, each of which is expressly incorporated herein by reference.